Systems, apparatus and methods for secure electrical communication of biometric personal identification information to validate the identity of an individual

ABSTRACT

An apparatus for validating an identity of an individual based on biometrics includes a memory and a processor operatively coupled to a distributed database and the memory. The processor is configured to provide biometric data as an input to a predefined hash function to obtain a first biometric hash value. The processor is configured to obtain, using a first pointer to the distributed database, a signed second biometric hash value. The processor is configured to define a certification of the biometric data in response to verifying that a signature of the signed second biometric hash value is associated with the compute device and verifying that the first biometric hash value corresponds with the second biometric hash value. The processor is configured to digitally sign the certification using a private key associated with the processor to produce a signed biometric certification and store the signed biometric certification in the distributed database.

BACKGROUND

The present application generally relates to systems, apparatus andmethods for secure electrical communication of biometric personalidentification information to validate the identity of an individual.Specifically, the present application relates to use of a distributeddatabase for identity validation using body characteristics and/orbiometric personal identification information.

In some known systems, biometrics can be stored and used for identityvalidation. Such systems, however, are often insecure and inefficient.Specifically, such known systems are subject to data breaches leavingbiometric data of users exposed. Moreover, such known systems are oftendifficult for multiple entities to use to validate an identity of anindividual using biometrics.

Accordingly, a need exists for secure and efficient systems, apparatusand methods for secure electrical communication of biometric personalidentification information to validate the identity of an individual.

SUMMARY

An apparatus for validating an identity of an individual based onbiometrics includes a memory and a processor operatively coupled to adistributed database and the memory. The processor is configured toreceive encrypted biometric data associated with a compute device anddecrypt the biometric data using a private key associated with theprocessor to obtain biometric data. The processor is configured toprovide the biometric data as an input to a predefined hash function toobtain a first biometric hash value. The processor is configured toreceive a first pointer to a record in the distributed databaseincluding a signed second biometric hash value and obtain, using thefirst pointer, the second biometric hash value from the distributeddatabase. The processor is configured to validate an identity of a userof the compute device in response to verifying that a signature of thesigned second biometric hash value is associated with the compute deviceusing a public key of the compute device and verifying that the firstbiometric hash value corresponds with the second biometric hash value.The processor is configured to define a certification based on thevalidating; digitally sign the certification using a private keyassociated with the processor to produce a signed biometriccertification; store the signed biometric certification in thedistributed database; and provide, to the compute device, a secondpointer to the signed biometric certification in the distributeddatabase such that the compute device can provide the second pointer toa relying entity.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows a simplified block diagram of a system and method forsealing an identity of a person in a public storage facility.

FIG. 1B also shows a simplified block diagram of a system and method forsealing an identity of a person in a public storage facility.

FIG. 1C shows a simplified block diagram of a system and method forsealing any input data in a public storage facility.

FIG. 2A shows a simplified block diagram of a system and method forcertifying an identity of a person.

FIGS. 2B-1 and 2B-2 show a process for verifying hashed input data and adigital signature.

FIG. 2C shows a simplified block diagram for recording anacknowledgment.

FIG. 3A shows a simplified block diagram of a system and method forverifying an acknowledgment record.

FIG. 3B shows a flowchart diagram for a method for verifying anacknowledgment record and its underlying certification record.

FIGS. 4A-4C are data flow diagrams illustrating the certification ofuser generated biometric data, in accordance with one embodiment of thepresent disclosure.

FIG. 5 is a data flow diagram illustrating secure data sharing via aserver, in accordance with one embodiment of the present disclosure.

Corresponding reference characters indicate corresponding partsthroughout the drawings.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth inorder to provide a thorough understanding of the exemplary embodiments.However, it will be apparent to one skilled in the art that the exampleembodiments may be practiced without some of these specific details. Inother instances, process operations and implementation details have notbeen described in detail, if already well known.

An apparatus for validating an identity of an individual based onbiometrics includes a memory and a processor operatively coupled to adistributed database and the memory. The processor is configured toreceive encrypted biometric data associated with a compute device anddecrypt the biometric data using a private key associated with theprocessor to obtain biometric data. The processor is configured toprovide the biometric data as an input to a predefined hash function toobtain a first biometric hash value. The processor is configured toreceive a first pointer to a record in the distributed databaseincluding a signed second biometric hash value and obtain, using thefirst pointer, the second biometric hash value from the distributeddatabase. The processor is configured to validate an identity of a userof the compute device in response to verifying that a signature of thesigned second biometric hash value is associated with the compute deviceusing a public key of the compute device and verifying that the firstbiometric hash value corresponds with the second biometric hash value.The processor is configured to define a certification based on thevalidating; digitally sign the certification using a private keyassociated with the processor to produce a signed biometriccertification; store the signed biometric certification in thedistributed database; and provide, to the compute device, a secondpointer to the signed biometric certification in the distributeddatabase such that the compute device can provide the second pointer toa relying entity.

FIG. 1A shows a simplified block diagram for a system 100 and method formanaging the identity of a user by way of making verifiable transactionswith a public storage facility 128. By way of example, an identificationcard 102 may be used. In other embodiments, other forms ofidentification, which may be digital or non-digital may be used. In theexample of the identification card 102, personal data 104 is containedthereon, which identifies the user. The personal data can include aphoto 106 of the user; the user's name, address and driver licensenumber 108, and/or a bar code 110 or similar computer code for storing,scanning and/or retrieving additional data. Such coding can includePDF417 codes, QR codes, and other such codes. However, it is notnecessary to have such code and the identification card may only havehuman-readable text strings. As noted above, the identification card 102may also take a physical or a digital form and the information can beretrieved either through scanning a code as described, performingOptical Character Recognition (OCR) on text strings, digitallytransferring a digital identification card from one system to another,manually inputting the information using a keyboard, manually inputtingthe information using voice recognition, etc., in example embodiments.

The identification card 102 can be a government issued form ofidentification such as a driver license, passport, employee badge,military identification, political documentation, or the like. Theidentification card 102 can also be a privately issued form ofidentification such as a student ID, library card, social club card, orany other form of identification issued by a third party.

In one embodiment, as indicated by triangle 114, an input device 112 maybe used to input such personal data from the identification card 102 toprovide input data. Input device 112 can take many forms. For example,input device 112 can be a digital scanner, digital camera, or smartphone(e.g., with the camera commonly found in smartphones) for reading datafrom the identification card 102, including any codes appearing on thecard 102. The input device 112 can also be a device for manuallyinputting personal data such as a keyboard, touchscreen, voicerecognition device, handwriting recognition device, or other manualinput device.

As shown in FIG. 1A, the input data can be optionally encrypted byencryption logic 118 and securely stored in operation 119 b. In oneimplementation, the input data is transferred directly to hashing logic120, without passing through encryption logic 118. For ease ofunderstanding, the operations of the optional encryption logic 118 willbe discussed first, and then the operations processed by the hashinglogic 120. As such, the process may proceed directly from receiving theuser information via 112 to the hashing logic 120.

The input data collected from the input device 112 (e.g., a user'ssmartphone) is passed to encryption logic 118 on input device 112. In anexample embodiment, encryption logic 118 might include software,firmware, hardware, or any combination thereof, and consist of one ormore encryption algorithms, e.g., an RSA encryption algorithm.Encryption logic 118 encrypts the input data with a public key toprovide encrypted data. The public key is paired with an associatedprivate key as is conventional when generating such keys using an RSAencryption algorithm, an Elliptic Curve Digital Signature Algorithm(ECDSA), or other encryption algorithm known to those skilled in theart. As shown in operation 119 b, this encrypted data can then be storedlocally on the input device 112 for added security. It can then only beaccessed with the private key of the user on the input device 112, whichmight be stored in a more secure part of input device 112, e.g., “theKeychain”, in operation 119 a, if input device 112 is an iOS (e.g.,operating system used by devices made by Apple, Inc.) smartphone. If thedevice is of a different type, e.g., one using an Android OS (e.g.,operating system by Google, Inc.), similar secure device storage methodsmay be used. In this manner, for added security, the private key is notcompromised and is kept safely on the input device 112. It should beunderstood that the private key may be stored on another device, butsimilar or additional security should be processed to ensure that theprivate key is not compromised.

As noted above, the operations to be performed by the hashing logic 120can proceed directly after receiving the input data from the inputdevice 112. In this embodiment, the hashing logic 120 is used forhashing the input data (e.g., personal information collected) to provideor generate a hash value. The hash value is sometimes referred to as“hash data,” that is generated by an algorithm. In an exampleembodiment, hashing logic 120 might be software, firmware, hardware, orany combination thereof, and consist of one or more hashing algorithms,e.g., a Secure Hash Algorithm (SHA) algorithm. Hashing logic 120 passesthe hash value to digital-signature logic 121, which performs a digitalsignature on the hash value, using the private key on the input device112. In an example embodiment, digital-signature logic 121 might be acomponent (or module) of encryption logic 118. In other embodiments, thedigital-signature logic 121 may be defined by separate code, firmware,and/or hardware.

In one embodiment, the digital-signature logic 121 then passes thesigned hash value and the public key to a user accessible interface 126(e.g., a graphical user interface or GUI), which might be other softwarerunning on the input device 112. In an example embodiment, the useraccessible interface 126 might be part of an application or app thatincludes encryption logic 118, hashing logic 120, and digital-signaturelogic 121, and/or other modules or code. The user accessible interface126 might be used by the user to transmit the digitally signed hashvalue and the public key to a public storage facility 128 via a line130, and receive back from the public storage facility 128 a transactionnumber 132 corresponding to the transmitted hash value and public key.As used in this disclosure, a “line” might be part of a wired and/orwireless connection or network, including a bus, an intranet, aninternet, an extranet, a public computer network, a private computernetwork, etc., in an example embodiment. In an alternative exampleembodiment, only the signed hash value might be transmitted to publicstorage facility 128 by the user and persons retrieving the signed hashvalue might obtain the public key from elsewhere (e.g., the user, apublic database, an Internet repository, a website, etc.). As is wellknown, there is no need to keep public keys secure, and in fact, thealgorithms using public/private key pairs are design to enable fullsharing of public keys. The private key, on the other hand, must be keptsecure, as noted above.

In one embodiment, the public storage facility 128 can take the form ofa block chain (e.g., in a bitcoin online payment system) or any otherpublic or private distributed database. The public storage facility 128is connected to a communication link via a line and can be adapted tocommunicate over a public computer network, the internet, an intranet,an extranet, or any private communication network. Broadly speaking, thepublic storage facility 128 is accessible by any device that has anInternet connection over a network. A block chain, as is known in theart, is a system that enables users' access to securely store data in apublic place. The data is deemed secure, as each time data is written,the written data is dependent on previously written data, which includesperforming cryptographic hash operations. A benefit of using a blockchain is that once data is written to the block chain and a block chaintransaction is created, that transaction remains intact, and can beverified in the future. The reason for this, is that data is continuallywritten to the block chain, e.g., after a particular transaction ismade, and that later data is dependent on an earlier particulartransaction. Consequently, by writing data to a public storage facilitythat implements a public block chain, later verification of that data ispractically ensured to be correct. In one embodiment, a distributedpublic database is a block chain, which receives data for storage from aplurality of entities. The entities need not be related, and the type ofdata need not be the same. In general, entities storing the block chainare unrelated, and the type of data can vary to almost any type ofdigital data, e.g., not limited to identity data, commercial data,bitcoin data, etc. Thus, the data received for storage is configured tobe processed to generate a transaction record that is dependent onprevious data stored to the block chain. The transaction record beingdependent on previous data stored to the block chain ensures that datastored to the block chain is not modifiable, as each later data storedto the block chain continues to be dependent on previous data stored tothe block chain.

As indicated above, in an example embodiment, the input data might behashed and the resulting hash value might be signed with a digitalsignature, created using a private key paired with a public key, beforetransmission, optionally along with the public key, from the inputdevice (e.g., a user's smartphone) 112 to the public storage facility128 for storage. The user accessible interface 126 is thus adapted to“seal” the signed hash value and the public key in the public storagefacility 128. In one embodiment, once the hash value, and optionally thepublic key of the user is written to the block chain in a transaction, alater verification may be made if another party is able to hash the sameinput data.

As depicted in FIG. 1B, user accessible interface 126 (e.g., a GUI) canbe controllable by the user of the input device 112 to encrypt andprovide the transaction number 132, the input data, and, optionally, thepublic key of the user, to an input device 142 (e.g., a smartphone) of athird party (e.g., a financial institution or other entity engaging in acommercial, private transaction, or other transaction with the user) to,for example, establish the identity of the user. In one embodiment, thethird party will access the block chain using the transaction number 132to retrieve the digitally signed hash value, and optionally, the publickey if the public key has not been previously obtained by the thirdparty from another source/location, and enable comparison with a hashvalue that is generated by the third party using the input data and thesame hashing algorithm.

In an example embodiment, the encryption of the transaction number 132,the input data, and, optionally, the public key of the user might beperformed by the encryption logic 118 using a public key of a thirdparty paired with a private key of the third party. Then, coding logic150 on the input device 112 might code the encrypted items into abarcode or QR code and the third party might use input device 142 toscan the barcode or QR code and decode it to gain access to theencrypted items. Thereafter, the third party might decrypt the encrypteditems using the private key of the third party to perform a verificationoperation. In one embodiment, the verification may use an RSA algorithmas explained in further detail below. Other verification algorithms mayalso be used, depending on the configured implementation.

FIG. 1C shows a simplified block diagram of a system and method forsealing any input data in a public storage facility. As noted above, theoperations to be performed by the hashing logic 120 can proceed directlyafter receiving the user information from the input device 112. In thisembodiment, the hashing logic 120 is used for hashing the input data(e.g., personal information collected) to provide or generate a hashvalue. The hash value is sometimes referred to as “hash data,” that isgenerated by an algorithm. In an example embodiment, hashing logic 120might be software, firmware, hardware, or any combination thereof, andconsist of one or more hashing algorithms, e.g., a Secure Hash Algorithm(SHA) algorithm. Hashing logic 120 passes the hash value todigital-signature logic 121, which performs a digital signature on thehash value, using the private key on the input device 112. In an exampleembodiment, digital-signature logic 121 might be a component (or module)of encryption logic 118. In other embodiments, the digital-signaturelogic 121 may be defined by separate code, firmware, and/or hardware.

In one embodiment, the digital-signature logic 121 then passes thesigned hash value and the public key to a user accessible interface 126(e.g., a graphical user interface or GUI), which might be other softwarerunning on the input device 112. In an example embodiment, the useraccessible interface 126 might be part of an application or app thatincludes encryption logic 118, hashing logic 120, and digital-signaturelogic 121, and/or other modules or code. The user accessible interface126 might be used by the user to transmit the digitally signed hashvalue and the public key to a public storage facility 128 via a line130, and receives back from the public storage facility 128 atransaction number 132 corresponding to the transmitted hash value andpublic key. In an alternative example embodiment, only the signed hashvalue might be transmitted to public storage facility 128 by the userand persons retrieving the signed hash value might obtain the public keyfrom elsewhere (e.g., the user, a public database, an Internetrepository, a website, etc.). As is well known, there is no need to keeppublic keys secure, and in fact, the algorithms using public/private keypairs are design to enable full sharing of public keys. The private key,on the other hand, must be kept secure, as noted above.

In one embodiment, the public storage facility 128 can take the form ofa block chain (e.g., in a bitcoin online payment system) or any otherpublic or private distributed database. The public storage facility 128is connected to a communication link via a line and can be adapted tocommunicate over a public computer network, the internet, an intranet,an extranet, or any private communication network. Broadly speaking, thepublic storage facility 128 is accessible by any device that has anInternet connection over a network.

As indicated above, in an example embodiment, the input data might behashed and the resulting hash value might be signed with a digitalsignature, created using a private key paired with a public key, beforetransmission, optionally along with the public key, from the inputdevice (e.g., a user's smartphone) 112 to the public storage facility128 for storage. The user accessible interface 126 is thus adapted to“seal” the signed hash value and the public key in the public storagefacility 128. In one embodiment, once the hash value, and, optionally,the public key of the user is written to the block chain in atransaction, a later verification may be made if another party is ableto hash the same input data.

FIG. 2A shows a simplified block diagram for a certification method formanaging the identity of a user in a public storage facility 228. By wayof example, an identification card 202 may be used. In otherembodiments, other forms of identification, which may be digital ornon-digital may be used. In the example of the identification card 202,personal data 204 is contained thereon, which identifies the user. Theinput data can include a photo 206 of the user; the user's name, addressand driver license number 208, and/or a bar code 210 or similar computercode for storing, scanning and/or retrieving additional data. Suchcoding can include PDF417 codes, QR codes, and other such codes.However, it is not necessary to have such code and the identificationcard may only have human-readable text strings. As noted above, theidentification card 202 may also take a physical or a digital form andthe information can be retrieved either through scanning a code asdescribed, performing Optical Character Recognition (OCR) on textstrings, digitally transferring a digital identification card from onesystem to another, manually inputting the information using a keyboard,manually inputting the information using voice recognition, etc., inexample embodiments.

The identification card 202 can be a government issued form ofidentification such as a driver license, passport, employee badge,military identification, political documentation, or the like. Theidentification card 202 can also be a privately issued form ofidentification such as a student ID, library card, social club card, orany other form of identification issued by a third party.

In one embodiment, as indicated by triangle 214, an input device 212 maybe used to input such personal data from the identification card 202 toprovide input data. Input device 212 can take many forms. For example,input device 212 can be a digital scanner, digital camera, or smartphone(e.g., with the camera commonly found in smartphones) for reading datafrom the identification card 202, including any codes appearing on thecard 202. The input device 212 can also be a device for manuallyinputting personal data such as a keyboard, touchscreen, voicerecognition device, handwriting recognition device, or other manualinput device.

As shown in FIG. 2A, the input data can be optionally encrypted byencryption logic 218 and securely stored. In one implementation, theinput data is transferred directly to hashing logic 220, without passingthrough encryption logic 218. For ease of understanding, the operationsof the optional encryption logic 218 will be discussed first, and thenthe operations processed by the hashing logic 220. As such, the processmay proceed directly from receiving the user information via 212 to thehashing logic 220.

The input data collected from the input device 212 (e.g., a user'ssmartphone) is passed to encryption logic 218 on input device 212. In anexample embodiment, encryption logic 218 might include software,firmware, hardware, or any combination thereof, and consist of one ormore encryption algorithms, e.g., an RSA encryption algorithm.Encryption logic 218 encrypts the input data with a public key toprovide encrypted data. The public key is paired with an associatedprivate key as is conventional when generating such keys using an RSAencryption algorithm, an Elliptic Curve Digital Signature Algorithm(ECDSA), or other encryption algorithm known to those skilled in theart. This encrypted data can then be stored locally on the input device212 for added security. It can then only be accessed with the privatekey of the user on the input device 212, which might be stored in a moresecure part of input device 212, e.g., “the Keychain”, if input device212 is an iOS (e.g., operating system used by devices made by Apple,Inc.) smartphone. If the device is of a different type, e.g., one usingan Android OS (e.g., operating system by Google, Inc.), similar securedevice storage methods may be used. In this manner, for added security,the private key is not compromised and is kept safely on the inputdevice 212. It should be understood that the private key may be storedon another device, but similar or additional security should beprocessed to ensure that the private key is not compromised.

As noted above, the operations to be performed by the hashing logic 220can proceed directly after receiving the input data from the inputdevice 212. In this embodiment, the hashing logic 220 is used forhashing the input data (or selected fields of the input data or personaldata) to provide or generate a hash value. The hash value is sometimesreferred to as “hash data,” that is generated by an algorithm. In anexample embodiment, hashing logic 220 might be software, firmware,hardware, or any combination thereof, and consist of one or more hashingalgorithms, e.g., a Secure Hash Algorithm (SHA) algorithm. Hashing logic220 passes the hash value to digital-signature logic 221, which performsa digital signature on the hash value, using the private key on theinput device 212. In an example embodiment, digital-signature logic 221might be a component (or module) of encryption logic 218. In otherembodiments, the digital-signature logic 221 may be defined by separatecode, firmware, and/or hardware.

In one embodiment, the digital-signature logic 221 then passes thesigned hash value and the public key to a user accessible interface 226(e.g., a graphical user interface or GUI), which might be other softwarerunning on the input device 212. In an example embodiment, the useraccessible interface 226 might be part of an application or app thatincludes encryption logic 218, hashing logic 220, and digital-signaturelogic 221, and/or other modules or code. The user accessible interface226 might be used by the user to transmit the digitally signed hashvalue and, optionally, the public key to a public storage facility 228via a line 230, and receive back from the public storage facility 228 atransaction number 232 corresponding to the transmitted hash value andpublic key.

In one embodiment, the public storage facility 228 can take the form ofa block chain (e.g., in a bitcoin online payment system) or any otherpublic or private distributed database. The public storage facility 228is connected to a communication link via a line and can be adapted tocommunicate over a public computer network, the internet, an intranet,an extranet, or any private communication network. Broadly speaking, thepublic storage facility 228 is accessible by any device that has anInternet connection over a network.

As indicated above, in an example embodiment, the input data (orselected fields of the input data) might be hashed and the resultinghash value might be signed with a digital signature, created using aprivate key paired with a public key, before transmission, along with,optionally, the public key, from the input device (e.g., a user'ssmartphone) 212 to the public storage facility 228 for storage. The useraccessible interface 226 is thus adapted to “seal” the signed hash valueand the public key in the public storage facility 228. In oneembodiment, once the hash value, and, optionally, the public key of theuser is written to the block chain in a transaction, a laterverification may be made if another party is able to hash the same inputdata.

The user accessible interface 226 (e.g., a GUI) can be controllable bythe user of the input device 212 to encrypt and provide the transactionnumber 232, the input data (or selected fields of the input data), and,optionally, the public key to an input device 242 (e.g., a smartphone)of a certifier. In an example embodiment, the encryption might beperformed by the encryption logic 218 using a public key of a certifierpaired with a private key of the certifier. Then, coding logic on theinput device 212 might code the encrypted transaction number 232, theinput data (or selected fields of the input data), and, optionally, thepublic key into a barcode or QR code and the certifier might use inputdevice 242 to scan the barcode or QR code and decode it to gain accessto the encrypted items. Thereafter, the certifier might decrypt theencrypted items using the private key of the certifier and verify them,e.g., using a “verify” function call to an RSA algorithm as explained infurther detail below.

Once the certifier's input device 242 receives the barcode or QR code,decoding logic on the certifier's input device 212 might decode thebarcode or QR code and decryption logic 270 on the certifier's inputdevice 242 might use the certifier's private key to decrypt theencrypted items. In an example embodiment, decryption logic 270 might bea component (or module) of more general encryption logic. In oneembodiment, the decrypted input data (or selected fields of the inputdata) might be hashed into a hash value by hashing logic 272 on thecertifier's input device 242, using the same hashing algorithm that wasused to create the hash value that was digitally signed by the user. Andthe decrypted transaction number 232 might be used by a user accessibleinterface 280 (e.g., a GUI) to access the public storage facility 228(e.g., the block chain) and retrieve the signed hash value and publickey of the user. The retrieved signed hash value, the generated hashvalue, and the retrieved or obtained public key might then be input toverifying logic 273 for verification (e.g., through a “verify” functioncall to an RSA algorithm), which outputs a “true” value if the two hashvalues are the same and the public key is associated with the signatureor a “false” value if the two hash values are not the same or the publickey is not associated with the signature. In an example embodiment,verifying logic 273 might be a component (or module) of decryption logic270. In another embodiment, the verifying logic 273 may be a separatemodule, software, firmware and/or hardware. As indicated above, in anexample embodiment, the public key of the user might be obtained fromsome other source than the public storage facility 228 (e.g., from theuser), in an example embodiment.

This verification process is depicted in FIGS. 2B-1 and 2B-2. FIG. 2B-1shows how a digitally signed hash value is created from input data. Theinput data (or selected fields of the input data) is hashed into a hashvalue “ABC” by hashing logic 220 on the user's input device 112, inoperation 1. Then the hash value “ABC” is digitally signed with theuser's private key using digital-signature logic 121 to create digitallysigned hash value “XYZ”, in operation 2.

FIG. 2B-2 shows how a digitally signed hash value is verified afterbeing retrieved along with the public key of the user from the publicstorage facility 228. The input data (or selected fields of the inputdata) is received from the user's input device 212 at the certifier'sinput device 242 and is hashed into a generated hash value “ABC” usinghashing logic 272, in operation 3. Then the signed hash value “XYZ”, thegenerated hash value “ABC”, and the user's public key are input toverification logic 273 in operation 4. The verification logic 273 mightinclude a RSA verification algorithm, in an example embodiment. If thehash value in the digitally signed hash value “XYZ” is the same as thegenerated hash value “ABC” and the digital signature was signed with aprivate key that is associated with the user's public key, theverification logic 273 returns a value of “true”. Otherwise theverification logic 273 returns a value of “false”. It should beunderstood that the verification logic 273 may be executed on any device(e.g., a user's device, a certifier's device, a verifier's device, athird party's device, a commercial entity's device, a private entity'sdevice, etc.), that needs to perform a verification operation.

Upon receipt of a “true” value from encryption logic 270, the certifiermight create a certification record that refers to the verification. Inan example embodiment, the certification record might include thetransaction number 232, the input data (or selected fields of the inputdata), received from the user, and, optionally, a timestamp, and thecertification record might be hashed and digitally signed by thecertifier using a private key of the certifier associated with a publickey. Then the certifier might use user accessible interface 280 (e.g., aGUI) to transmit the signed certification record to the public storagefacility 228 for storage and receive in return transaction number 282from the public storage facility 228. In an example embodiment, thecertifier might encrypt the certification record with the certifier'spublic key before transmission to the public storage facility 228, inorder to keep the certification record private.

It will be appreciated that the verification process shown in FIGS. 2B-1and 2B-2 might be used to verify the digital signature on items of dataother than the input data (or selected fields of the input data)received by input device 212. In an example embodiment, the item of datathat is digitally signed might not be hashed before being digitallysigned. In an example embodiment, the verification process shown inFIGS. 2B-1 and 2B-2 might be used to verify a digitally-signed hash of adocument other than an identification card, e.g., a digitally-signedcertification as described above or a digitally-signed acknowledgment asdescribed below. Or, the same verification process might be used toverify a digitally-signed token (e.g., random number) that is sent by asender using a secure-envelope process. A secure-envelope process, asdescribed below, might be used instead of, or in addition to, public-keyencryption when transmitting data from a user to a certifier, verifier,third party, etc., and vice versa.

In an example embodiment, when using a secure envelope process, a sendermight hash a real-time token (e.g., a random number generated by theuser's remote device) and digitally sign the hashed token using thesender's private key. In an example embodiment, a timestamp might beoptionally included with the token. Then the sender might transmit thesigned hashed token and, optionally, the public key associated with thesender's private key to a distributed public database for storage,receiving a transaction number in return from the distributed publicdatabase. Thereafter, the sender might transmit the transaction numberand the token to a receiver, e.g., a certifier, a verifier, a thirdparty, etc., optionally, after encrypting the transaction number and thetoken with the receiver's public key. In an example embodiment, thereceiver might receive the transaction number and token (optionallyincluding the timestamp), decrypt them using the receiver's private key,if necessary, and then use the transaction number to retrieve thedigitally signed hashed and, optionally, the sender's public key fromthe distributed public database. The receiver might generate a hash ofthe token using the same hashing algorithm the sender used. Then thereceiver might verify, e.g., using an RSA verify call as describedabove, that the token in the generated hash is the same as the token inthe digitally signed hash token and verify that the digital signaturewas created with the sender's private key. An RSA verify call may be,for example, processed by verifying logic 273, e.g., to execute a verifyoperation. In an example embodiment, the token (optionally including thetimestamp) might not be hashed before being signed.

In one configuration, as depicted in FIG. 2C, the certifier mightencrypt the certification record and transaction number 282 (e.g., thetransaction number the certifier received from the public storagefacility 228) with the user's public key and transmit in 281 theencrypted certification record to the user, using user accessibleinterface 280 (e.g., a GUI). Upon receiving the encrypted certificationrecord, the user might decrypt it using the user's private key and thencreate an acknowledgment record that refers to or includes thecertification record, and optionally includes a timestamp, in order tolink the two records in the public storage facility 228 to facilitateconvenient lookup by a third party, if the certification record isverified. Here again, to verify the certification record, the user mighthash the certification record using the same hashing algorithm that thecertifier used prior to digital signature by the certifier. The usermight use transaction number 282 to retrieve the signed certificationrecord and the certifier's public key from the public storage facility228. Then the user might verify that the certification record in thegenerated hash is the same as the certification record in the digitallysigned certification record and verify that the digital signature wascreated with the certifier's private key, e.g., using an RSA verify callas described above.

In an example embodiment, the acknowledgment record might include thecertification record, the transaction number 282, and optionally, atimestamp, and the user might digitally sign the acknowledgment recordwith the user's private key. Then the user might use user accessibleinterface 228 (e.g., a GUI) to transmit the signed acknowledgment recordand the user's public key to the public storage facility 228 for storageand receive a transaction number 229 in response from the public storagefacility 228. In an example embodiment, the user might encrypt thesigned acknowledgment record with the user's public key beforetransmission to the public storage facility 228 in order to keep theacknowledgment record private.

FIG. 3A shows a simplified block diagram for a system and method forcertifying a pending transaction. By way of example, an identificationcard 302 may be used. In other embodiments, other forms ofidentification, which may be digital or non-digital may be used. In theexample of the identification card 302, personal data 304 is containedthereon, which identifies the user. The personal data can include aphoto 306 of the user; the user's name, address and driver licensenumber 308, and/or a bar code 310 or similar computer code for storing,scanning and/or retrieving additional data. Such coding can includePDF417 codes, QR codes, and other such codes. However, it is notnecessary to have such code and the identification card may only havehuman-readable text strings. As noted above, the identification card 302may also take a physical or a digital form and the information can beretrieved either through scanning a code as described, performingOptical Character Recognition (OCR) on text strings, digitallytransferring a digital identification card from one system to another,manually inputting the information using a keyboard, manually inputtingthe information using voice recognition, etc., in example embodiments.

The identification card 302 can be a government issued form ofidentification such as a driver license, passport, employee badge,military identification, political documentation, or the like. Theidentification card 302 can also be a privately issued form ofidentification such as a student ID, library card, social club card, orany other form of identification issued by a third party.

In one embodiment, as indicated by triangle 314, an input device 312 maybe used to input such personal data from the identification card 302 toprovide input data. Input device 312 can take many forms. For example,input device 312 can be a digital scanner, digital camera, or smartphone(e.g., with the camera commonly found in smartphones) for reading datafrom the identification card 302, including any codes appearing on thecard 302. The input device 312 can also be a device for manuallyinputting personal data such as a keyboard, touchscreen, voicerecognition device, handwriting recognition device, or other manualinput device.

As shown in FIG. 3A, the input data can be optionally encrypted byencryption logic 318 and securely stored. In one implementation, theinput data is transferred directly to hashing logic 320, without passingthrough encryption logic 318. For ease of understanding, the operationsof the optional encryption logic 318 will be discussed first, and thenthe operations processed by the hashing logic 320. As such, the processmay proceed directly from receiving the user information via 312 to thehashing logic 320.

The input data collected from the input device 312 (e.g., a user'ssmartphone) is passed to encryption logic 318 on input device 312. In anexample embodiment, encryption logic 318 might include software,firmware, hardware, or any combination thereof, and consist of one ormore encryption algorithms, e.g., an RSA encryption algorithm.Encryption logic 318 encrypts the input data with a public key toprovide encrypted data. The public key is paired with an associatedprivate key as is conventional when generating such keys using an RSAencryption algorithm, an Elliptic Curve Digital Signature Algorithm(ECDSA), or other encryption algorithm known to those skilled in theart. This encrypted data can then be stored locally on the input device312 for added security. It can then only be accessed with the privatekey of the user on the input device 312, which might be stored in a moresecure part of input device 312, e.g., “the Keychain”, if input device312 is an iOS (e.g., operating system used by devices made by Apple,Inc.) smartphone. If the device is of a different type, e.g., one usingan Android OS (e.g., operating system by Google, Inc.), similar securedevice storage methods may be used. In this manner, for added security,the private key is not compromised and is kept safely on the inputdevice 312. It should be understood that the private key may be storedon another device, but similar or additional security should beprocessed to ensure that the private key is not compromised.

As noted above, the operations to be performed by the hashing logic 320can proceed directly after receiving the user information from the inputdevice 312. In this embodiment, the hashing logic 320 is used forhashing the input data (or selected fields of the input data or personaldata) to provide or generate a hash value. The hash value is sometimesreferred to as “hash data,” that is generated by an algorithm. In anexample embodiment, hashing logic 320 might be software, firmware,hardware, or any combination thereof, and consist of one or more hashingalgorithms, e.g., a Secure Hash Algorithm (SHA) algorithm. Hashing logic320 passes the hash value to digital-signature logic 321, which performsa digital signature on the hash value, using the private key on theinput device 312. In an example embodiment, digital-signature logic 321might be a component (or module) of encryption logic 318. In otherembodiments, the digital-signature logic 321 may be defined by separatecode, firmware, and/or hardware.

In one embodiment, the digital-signature logic 321 then passes thesigned hash value and, optionally, the public key to a user accessibleinterface 326 (e.g., a graphical user interface or GUI), which might beother software running on the input device 312. In an exampleembodiment, the user accessible interface 326 might be part of anapplication or app that includes encryption logic 318, hashing logic320, and digital-signature logic 321, and/or other modules or code. Theuser accessible interface 326 might be used by the user to transmit thedigitally signed hash value and, optionally, the public key to a publicstorage facility 328 via a line 330, and receive back from the publicstorage facility 328 a transaction number 332 corresponding to thetransmitted hash value and public key.

In one embodiment, the public storage facility 328 can take the form ofa block chain (e.g., in a bitcoin online payment system) or any otherpublic or private distributed database. The public storage facility 328is connected to a communication link via a line and can be adapted tocommunicate over a public computer network, the internet, an intranet,an extranet, or any private communication network. Broadly speaking, thepublic storage facility 328 is accessible by any device that has anInternet connection over a network.

As indicated above, in an example embodiment, the input data might behashed and the resulting hash value might be signed with a digitalsignature, created using a private key paired with a public key, beforetransmission, optionally along with the public key, from the inputdevice (e.g., a user's smartphone) 312 to the public storage facility328 for storage. The user accessible interface 326 is thus adapted to“seal” the signed hash value and the public key in the public storagefacility 328. In one embodiment, once the hash value, and, optionally,the public key of the user is written to the block chain in atransaction, a later verification may be made if another party is ableto hash the same input data.

The user accessible interface 326 (e.g., a GUI) can be controllable bythe user of the input device 312 to transmit, in 350, an acknowledgmentrecord, a transaction number for a signed acknowledgment record, andoptionally the user's public key to a verifier 342. In an exampleembodiment, transaction number 332 for the signed input data and theinput data might also be transmitted to verifier 342, for verificationusing the verification process used by the certifier, as describedabove. As used herein, to provide broad understanding of the functionsor operation of verifier 342, an example use case of a bank, being theverifier is provided. It should be understood that the verifier can beany entity that needs to verify identity, data, or transaction(s).Additionally, the certifier may be any entity that has certifiedidentity, data, or transaction(s). Thus, in this use case example, thebank is not necessarily the same entity as the certifier, but in othercircumstances, the bank may also be the certifier. By way of example,the bank may verify a certification made by another entity, e.g., acredit card company, a car company, a government agency, a privateentity, etc. Acknowledgment records and transaction numbers for signedacknowledgment records were discussed in detail above with respect toFIG. 2C. As noted indicated above, the user might use encryption withthe verifier's public key and/or a secure-envelope process fortransmission 350.

Once the verifier receives the acknowledgment record and the transactionnumber for the signed acknowledgment record, the verifier might use theprocess shown in FIG. 3B to verify the acknowledgment record and itsunderlying certification record. In operation 1, the verifier uses thetransaction number to retrieve the signed acknowledgment record and,optionally, the user's public key from public storage facility 328.Then, in operation 2, the verifier hashes the acknowledgment record withthe same hashing algorithm that was used by the user and verifies theacknowledgment record and the user's signature, using a verificationalgorithm as discussed in detail above. If the verification issuccessful, the verifier uses the transaction number for the signedcertification record to retrieve the signed certification record and thecertifier's public key from public storage facility 328, in operation 3.Then, in operation 4, the verifier hashes the certification record withthe same hashing algorithm that was used by the certifier and verifiesthe certification record and the certifier's signature, using averification algorithm as discussed in detail above. If thisverification is also successful, the verifier might create anothercertification record as discussed above and transmit it to publicstorage facility 328, receiving, in response, another transactionnumber, which might be transmitted along with the verifier'scertification record to the user for another acknowledgment record.

In the event the certification record and/or the acknowledgment recordare optionally encrypted before transmission to the block chain, theuser transmits an unencrypted acknowledgment record to the verifier andthe verifier performs its verifications using the data in theunencrypted acknowledgment record. In an example embodiment, theseverifications include checking that an acknowledgment record in factexists in the block chain with the transaction number for the signedacknowledgment record. Also, in an example embodiment, the unencryptedacknowledgment record includes the transaction number of the signedcertification record along with other unencrypted data from thecertification record. Using the transaction number for the signedcertification and the unencrypted data from the certification record,the verifier can confirm that the certification record in fact exists onthe block chain and can process the unencrypted data in thecertification record to verify the certifier's signature, even if thecertification record was also encrypted before transmission to the blockchain.

Certified User Generated Data (Biometrics)

A User may generate any type of data (UGD) and have that data Certifiedby a third party (Certifier). There are no limitations as to the type ofdata generated. The data can be any of the following types, but notlimited only to these types of data: 1) a simple text string; 2) a date;3) an enumerated data type; 4) a number; 5) an arbitrary series of databytes (e.g., a data block).

For distinction, the data types would have a name associated with them,so they appear in the form: Name=Value.

This data would be saved locally on the Users' mobile App. The Userwould then Seal her record by writing this data to the blockchain. Thiscan be done by either inserting a new Seal record with the added usergenerated data that overwrites any previous Seal (if any), or a new Sealthat complements any prior Seals.

The value field written to the block chain is for validation of theoriginal data only. The user is expected to hold onto that data and onlyshare it when the user chooses to. Hence, the data is first hashed sothe UGD becomes <hash.UGD>. Any number of hashing algorithms can be usedsuch as SHA256. The user then signs the <hash.UGD> with its private keyproducing <signed.hash.UGD>. This becomes the value that is then writtento the blockchain in the form: Name=<signed.hash.UGD>.

Once the record is sealed, the User may then present the UGD (maintainedby the User or another device storage of his/her choosing), along withher public-key and a pointer to the Seal record on the blockchain toanother party.

The other party (the Certifier) can then get the hash value of the UGDby hashing the data with the same algorithm. This produces <hash.UGD>.The Certifier can then use <hash.UGD>, the users' public-key and the<signed.hash.UGD> pointed to on the blockchain to confirm that the datagiven to it is what was Sealed on the blockchain.

The Certifier can then inspect the UGD in its clear form forauthenticity, approval, or agreement.

If the Certifier chooses to, it may then certify that data. To Certifythat record, it uses methods previously described to uniquely certifythe <signed.hash.UGD>. By doing so, at any point in the future, the usermay present the UGD along with a pointer to its Sealed record and theCertified record along with its public-key to the Certifier or any otherthird party. To the degree that these parties trust the originalCertifier who certified the record, the third party or the Certifier canvalidate the certification and matching of the UGD to the signature onthe blockchain and feel comfortable to use the UGD without separatelyauthenticating, approving, or agreeing to the data. The UGD waspreviously authenticated, approved or agreed to by the Certifier, atrusted party.

The contents of the UGD may now be used for additional activities. Ifthe UGD is a contract, its content can be trusted to the degree that theCertification attests to it. The UGD may be biometric data such as afingerprint, facial image, iris-scan, voice, DNA-data or other biometricdata. If the Certification represented a relationship of that data tothe user, the third party presented with the data and the Certificationcan trust that association to the degree that it trusts the Certifier.

For example, if a government agency Certifies a users' UGD (that is abiometric data) as association of that biometric data with the givenUser, the User can later present that same UGD to the same governmentagency or anyone else who accepts that government agency's certificationprocess (the Verifier). The Verifier can now capture a new biometricfrom the same person (e.g., capture a new finger print, a new facialimage, a new DNA-sample, a new iris-scan, a new voice-sample, or otherbiometric data) and compare it with the UGD that the User presented. Ifthe two match, the Verifier can be assured that this is the sameindividual as the person who was previous Certified by the governmentagency. This not only validates the Users' digital id presented, butalso the physical person who just presented that.

Similar evaluations can be done with the UGD, if it is any other datasuch as a date, a simple text-string, an enumerated data-type, a number,or any arbitrary set of data bytes.

FIGS. 4A-4C combined illustrate in more detail the process forcertifying user generated biometric data as described above, inaccordance with embodiments of the present disclosure. In particular,FIG. 4A-4C are data flow diagrams illustrating the certification of usergenerated biometric data. Participants (e.g., devices, systems, etc.)include user 405, certifier 420, verifier 430, and blockchain 450.

FIG. 4A illustrates operations performed at the user 405. At 451, usergenerated data (UGD) is captured. At 452, the UGD is hashed to generate:<hash.UGD>. Also, a signature of the hashed UGD is performed using theprivate key of the user to generate: <signed.hash.UGD>. At 453, to sealthe signature of the hashed UGD, a seal name is delivered to theblockchain, wherein the seal name is the signature of the hashed UGD. At454, a seal transaction identifier (“Seal txn-ID”) is returned to theuser 405 from the blockchain 450.

FIG. 4B illustrates operations performed at the certifier 420. At 461,the user presents to the certifier 420 the user generated data (UGD),the public key of the user (PBK.user), and the seal transactionidentifier (e.g., “Seal txn-ID”). At 462, the certifier 420 gets theseal record from the blockchain 450 using the seal transactionidentifier (e.g., “Seal txn-ID”). At 463, the seal record is returned tothe certifier 420 from the blockchain 450. At 464, from the seal recordthe signature of the hashed UGD (<signed.hash.UGD>) is extracted. Agenerated hash value (<hash.UGD>) is created by the certifier 420 byperforming a hash operation on the user generated data received from theuser. In addition, the certifier verifies that the generated hash value(<hash.UGD>) matches the hash value in the signature of the hashed UGD(<signed.hash.UGD>) using in part the public key of the user. At 465, ifthe generated hash value is verified at 466, then the raw data of theuser generated data (UGD) is checked for validation purposes. If the rawUGD is validated, then a certification signature of the seal transactionidentifier (e.g., “Seal txn-ID”), and possibly other data, is generatedusing the private key of the certifier is generated (“CertSig”). Also, acertification record (“CertRecord”) is generated by signing thecertifier seal transaction identifier, the seal transaction identifier,and possibly other information such as the field=name, and CertSig.Thereafter, a certification is performed. In particular, thecertification record is written and/or sealed to the blockchain at 466.At 467, a certification record transaction identifier (“CertRecordtxn-ID”) is returned to the certifier 420. At 468, the certificationrecord transaction identifier (“CertRecord txn-ID”) is delivered to theuser 405.

FIG. 4C illustrates operations performed at the verifier 430. At 471,the user 405 presents to the verifier 430 the user generated data (UGD),the public key of the user, the seal transaction identifier (Sealtxn-ID), and the certification record transaction identifier(“CertRecord txn-ID”). At 472, the verifier 430 then presents the sealtransaction identifier (Seal txn-ID) and the certification recordtransaction identifier (“CertRecord txn-ID”) to the blockchain 450 toretrieve the sealed records. At 473, the blockchain 450 delivers to theverifier 430 the seal record (“SealRecord”) and the certification record(“CertRecord”) stored to the blockchain. At 474 the verifier extractsthe signed hash of the user generated data. The verifier also hashes theuser generated data by performing a hash algorithm on the UGD to createa generated hash value (<hash.UGD>). Also, the verifier 430 verifiesthat the generated hash value (<hash.UGD>) matches the hash value in thesignature of the hashed UGD (<signed.hash.UGD>) from the seal record(“SealRecord”) using in part the public key of the user. At 475, if thegenerated hash value is verified, then the verifier 430 may retrieve thesealed certification record using the certifier seal transactionidentifier (“certifier Seal txn-ID”). At 476, the sealed certificationrecord (Certifier Seal Record) is returned to the verifier 430 from theblockchain 450. At 477, the verifier 430 verifies that the informationin the sealed certification record matches presented data. For example,the certification signature (CertSig) in the sealed certification recordis verified against newly presented CertSig data. At 478, if the data isverified, then the verifier 430 verifies that the user generated data(UGD) is sealed and certified by the certifier 420.

Exchange of Data Securely Via a Secure Envelope Between Two Users Via aServer

It is possible to provide the secure exchange of data described in theprior section by using a server. This can be handy if it is not feasibleto exchange large data sets between two users. For example, User A maybe on a mobile device and user B may be also on a mobile device or eveninteract via a web page. The two users in this case cannot exchange datadirectly without having a communication path. One way, they can sharedata is through digital codes such as a bar-code, a QR code,pdf-417-code or any other similar type of displayable codes. Thissection describes how variable sizes of data blocks (potentially verylarge data blocks) can be securely exchanged between such two parties byutilizing a server in the middle. This description outlines a methodwhere the server stores and directs the messages for the two parties,but is unable to ever read any of its content, in one embodiment. Theserver in the middle is depicted by the name “Store” 520 in thisdescription, but it can be any server.

The assumption in this exchange is that the two users already know oneanother and are aware of each others' SealId, and ultimately each otherpublic keys that are associated with corresponding private keys theyhave used to Seal their identification.

User A intends to send a block of data to user B. User A places thatdata in a data block and may add additional identification fields tothat block of data such as timestamp, its own

SealId, User B's SealId, its public key and if there is a sessionbetween the two, a sessionId. The value of the timestamp and thesessionId is to ensure vitality of the data block versus one that mayhave been created and somehow reused again. This data block will bereferred to as <dataBlock>.

Next, User A uses its own private key to digitally sign the <dataBlock>that was created. The result is <envelopeSignature>. Next, an<envelopeContent> is created by putting together the <dataBlock> and the<envelopeSignature>. Last, a <secureEnvelope> is created by encryptingthe <envelopeContent> with User B's public key.

Once a <secureEnvelope> is created by User A, the <secureEnvelope> issent to Store. Store creates a unique <messageId> that is associatedwith the <secureEnvelope> and it returns that id to User A.

User A then relays the <messageId> and possibly the address of the Storeserver (if not a well known server service between the two Users) toUser B. This data is rather short and can easily fit in nearly digitalcodes such as a bar code, a QR code, pdf-417-code and the like. User Breceives the data in some form, such as scanning the code from themobile screen of User A and then sends a message to Store to get the<secureEnvelope> associated with the <messageId>. Store returns theassociated <secureEnvelope>. If the protocol requires that thetransmission be a onetime process, the <secureEnvelope> can be deletedafter a successful transmission. It is also possible to delete theenvelope if an expiration time is associated with it.

This secure envelope can now be transmitted to user B from the store.User B can view the <envelopeContent> by decrypting the <secureEnvelope>using his private key that no one else is aware of. It may then verifythe <dataBlock> in the envelope content by verifying the <dataBlock> andthe <envelopeSignature> with the user A's public key that was passed. Itmay also verify that this is the same public key that was used in userA's SealId.

There is no restriction as to how User A passes the secure envelope toUser B. It can be done via email, a text message, NFC, or any other formof digital communication where the data can be passed. Because it isencrypted using User B's public key, only User B can view the messageand no other use can modify it either. In fact, after the secureenvelope is created, even User A can no longer view its content, in oneembodiment.

FIG. 5 in more detail shows the exchange of data securely via a SecureEnvelope between two users via a server as described above, inaccordance with one embodiment of the present disclosure. The secureenvelope exchange disclosed in FIG. 5 includes participants: User A,User B, and Store 520. The assumption in this exchange is that the twoUsers A and B already know one another and are aware of each others'SealId (e.g., “SealID.userA” and “SealID.userB”), and may be obtainedfrom seal records on a corresponding blockchain.

At 531, user A creates a data block <dataBlock> to include: the data tobe exchanged, a timestamp, the seal identifier of user A (SealID.userA),the seal identifier of user B (SealID.userB), a session identifier(sessionID) if available, and the public key of user A.

At 532, user A signs the data block using the private key of user A togenerate an envelope signature <envelopeSignature>. Also, an envelope<EnvelopeContent> is generated having contents including the data blockand the envelope signature <envelopeSignature>. A secure envelope<secureEnvelope> may be generated by encrypting the contents of theenvelope <EnvelopeContent> using the public key of user B.

At 533, user A sends the secure envelope <secureEnvelope> to store 520.At 534, store 520 may create a unique message identifier <messageID> tobe used as an index for accessing the secure envelope <secureEnvelope>.At 535, the message identifier <messageID> is delivered from store 520to user A.

At 536, the message identifier <messageID> is delivered from user A touser B. at 537, user B accesses the secure envelope <secureEnvelope> bysending message identifier <messageID> to store 520. At 538 the secureenvelope <secureEnvelope> is delivered from store 520 to user B. At 539,the secure envelope <secureEnvelope> may be removed from store 520 if itgenerated for purposes of a one-time use.

At 540, user B extracts the contents of the secure envelope<secureEnvelope> by decrypting the secure envelope <secureEnvelope>using the private key of user B. The data block that is extracted isverified using the envelope signature <envelopeSignature> and the publickey of user A.

It should be understood that the embodiments and described use casesherein are only by way of example. Many new use cases can be encompassedand facilitated by the functionality described herein. For instance,identity verification can be integrated into various commercialapplications, as well as private applications. Commercial applicationsmay include those that require commercial entities to verify a user'sidentity. Verifying a user's identity can be required for achieving anynumber of functions, such as traveling, making transactions, banking,communication, loan verification, credit verification, purchaseverification, and other uses. Private identity verification can also befacilitated using the methods, apparatus, computer readable media, andsystems described herein. Private identity verification may be usefulwhen a user wishes to prove to another user their identity, in a fastand efficient manner. The systems described herein, as described above,utilize methods that write data to the block chain database, which isnon-rewritable and permanently maintains the record without compromise.This enables writing of information to the block chain in a manner thatcan be verified by one or more transactions executed by methods of thepresent inventions.

Additionally, the method operations described herein may be executedwith any number of computer systems. By way of example, the computersystems may include user devices, such as mobile phones, tablets,desktop computers, watch computers, head attached computers, eyeglassescomputers, or combinations thereof. Server operations may also beperformed and communicated between client devices, to facilitatetransactions with the block chain database, server storage, and thelike. By way of example, these computer devices can communicate overnetworks, such as the Internet. The networks enable individual devicesto transact with each other, such as by way of sending, receiving, andprocessing exchanged information. The exchanged information can includedifferent types of encrypted data, hashed data, envelopes, codes, QRcodes, messages, notifications, and other types of data.

The messaging and communication functions are provided to enable usersto exchange data in order to verify identity, or enable or provideaccess to users to services, goods, or commercial transactions. In thecase of banking operations, the verification process can be utilized bybanks, as well as users of the bank or third parties that requirecertified information from the banks regarding users. In the case oftravel type verifications, different travel entities can requireidentification of users, and that the identification be verified bythemselves or by other third parties that are trusted. These operationscan be facilitated using the systems, methods, computer readable media,and code that execute the verification processes. Broadly speaking,verification of a user identity can be useful in any type of industry,or private setting. The use of verification is simply facilitated byusing the verifying infrastructure, programs code, applications, andcombinations thereof, to ensure that verification is secure.

In some embodiments, the verification systems can be embodied in anapplication, such as those that can be installed on mobile devices(e.g., Apps). By way of example, users wishing to have their identityverified can use an App to seal information regarding their identity.Once the data has been sealed, and encrypted data has been stored to theblock chain, this data can be used for later certification by anotherparty. The other party may also be utilizing a corresponding App, whichenables efficient reading of the data, code, QR code, message, ornotification, to validate the identity of the user.

In still other embodiments, code plug-ins can be integrated intocommercial websites, which may use identity verification for differentreasons or functions. For example, banks can install plug-inapplications, code, or programs that can execute part or all of theverification processing to seal information and/or to certifyinformation regarding identity. In view of the foregoing, it should beunderstood that the verifying processes described herein and the varioususe cases are only by way of example, and additional use cases will beevident to those skilled in the art.

In an example embodiment, a method is described. According to themethod, logic on a remote device causes the capture of personal dataidentifying a user from an identification card. The remote devicesupports a user-accessible interface. The logic generates a hash valuefrom the personal data using a hashing algorithm and signs the hashvalue with a digital signature created using a private key paired with apublic key. Then the logic transmits, over a network, the signed hashvalue and the public key from the remote device to a distributed publicdatabase for storage. The logic then receives, over the network, atransaction number from the distributed public database and, transmitsusing the user-accessible interface, the transaction number and thepersonal data to a remote device of a third party for certificationand/or verification.

In another example embodiment, another method is described. According tothe method, logic on a first remote device causes the capture ofpersonal data identifying a user from an identification card. The firstremote device supports a user-accessible interface. The logic generatesa hash value from the personal data using a hashing algorithm and signsthe hash value with a digital signature created using a first privatekey paired with a first public key. Then the logic transmits, over anetwork, the signed hash value and the first public key from the remotedevice to a distributed public database for storage. The logic thenreceives, over the network, a first transaction number from thedistributed public database.

The logic then transmits the first transaction number and the personaldata to a second remote device, wherein logic on the second remotedevice (a) uses the first transaction number to retrieve the signed hashvalue and the first public key from the distributed public database, (b)hashes the personal data using the hashing algorithm to create agenerated hash value, (c) verifies that the hash value in the signedhash value is the same as the generated hash value, (d) verifies thatthe signed hash value was signed with the first private key, and (c)creates a certification.

In another example embodiment, another method is described. According tothe method, logic on a first smartphone causes the capture of personaldata identifying a user from an identification card. The logic generatesa hash value from the personal data using a hashing algorithm and signsthe hash value with a digital signature created using a first privatekey paired with a first public key. Then the logic transmits, over anetwork, the signed hash value and the first public key from the remotedevice to a block chain database for storage. The logic then receives,over the network, a first transaction number from the block chaindatabase.

The logic then transmits the first transaction number and the personaldata to a second smartphone, wherein logic on the second smartphone (a)uses the first transaction number to retrieve the signed hash value andthe first public key from the block chain database, (b) hashes thepersonal data using the hashing algorithm to create a generated hashvalue, (c) verifies that the hash value in the signed hash value is thesame as the generated hash value, (d) verifies that the signed hashvalue was signed with the first private key, and (c) creates acertification.

Other aspects and advantages of the inventions will become apparent fromthe detailed description, taken in conjunction with the accompanyingdrawings, which illustrate by way of example the principles of theinventions.

The various embodiments defined herein may define individualimplementations or can define implementations that rely on combinationsof one or more of the defined embodiments. Further, embodiments of thepresent invention may be practiced with various computer systemconfigurations including hand-held devices, microprocessor systems,microprocessor-based or programmable consumer electronics,minicomputers, mainframe computers and the like. The invention can alsobe practiced in distributed computing environments where tasks areperformed by remote processing devices that are linked through awire-based or wireless network.

Any of the operations described herein that form part of the inventionare useful machine operations. The invention also relates to a device oran apparatus for performing these operations. The apparatus can bespecially constructed for the required purpose, or the apparatus can bea general-purpose computer selectively activated or configured by acomputer program stored in the computer. In particular, variousgeneral-purpose machines can be used with computer programs written inaccordance with the teachings herein, or it may be more convenient toconstruct a more specialized apparatus to perform the requiredoperations.

The invention can also be embodied as computer readable code on acomputer readable medium. The computer readable medium is any datastorage device that can store data, which can thereafter be read by acomputer system. The computer readable medium can also be distributedover a network-coupled computer system so that the computer readablecode is stored and executed in a distributed fashion.

Having provided this detailed description, it will be apparent thatmodifications and variations are possible without departing from thescope of the invention defined in the appended claims. When introducingelements of the present invention or the preferred embodiments(s)thereof, the articles “a”, “an”, “the” and “said” are intended to meanthat there are one or more of the elements. The terms “comprising”,“including” and “having” are intended to be inclusive and mean thatthere may be additional elements other than the listed elements. In viewof the above, it will be seen that the several objects of the inventionare achieved and other advantageous results attained. As various changescould be made in the above systems without departing from the scope ofthe invention, it is intended that all matter contained in the abovedescription and shown in the accompanying drawings shall be interpretedas illustrative and not in a limiting sense.

With the above embodiments in mind, it should be understood that theinventions might employ various computer-implemented operationsinvolving data stored in computer systems. Any of the operationsdescribed herein that form part of the inventions are useful machineoperations. The inventions also relate to a device or an apparatus forperforming these operations. The apparatus may be specially constructedfor the required purposes, such as the carrier network discussed above,or it may be a general purpose computer selectively activated orconfigured by a computer program stored in the computer. In particular,various general purpose machines may be used with computer programswritten in accordance with the teachings herein, or it may be moreconvenient to construct a more specialized apparatus to perform therequired operations.

The inventions can also be embodied as computer readable code on acomputer readable medium. The computer readable medium is any datastorage device that can store data, which can thereafter be read by acomputer system. Examples of the computer readable medium include harddrives, network attached storage (NAS), read-only memory, random-accessmemory, CD-ROMs, CD-Rs, CD-RWs, DVDs, Flash, magnetic tapes, and otheroptical and non-optical data storage devices. The computer readablemedium can also be distributed over a network coupled computer systemsso that the computer readable code is stored and executed in adistributed fashion.

Although example embodiments of the inventions have been described insome detail for purposes of clarity of understanding, it will beapparent that certain changes and modifications can be practiced withinthe scope of the following claims. For example, the web site might hostan online retailer or an online publication, instead of aconnected-television service. Moreover, the operations described abovecan be ordered, modularized, and/or distributed in any suitable way.Accordingly, the present embodiments are to be considered asillustrative and not restrictive, and the inventions are not to belimited to the details given herein, but may be modified within thescope and equivalents of the following claims. In the following claims,elements and/or steps do not imply any particular order of operation,unless explicitly stated in the claims or implicitly required by thedisclosure.

What is claimed is:
 1. An apparatus, comprising: a memory; and aprocessor operatively coupled to a distributed database and the memory,the processor configured to: receive encrypted biometric data associatedwith a compute device; decrypt the biometric data using a private keyassociated with the processor to obtain biometric data; provide thebiometric data as an input to a predefined hash function to obtain afirst biometric hash value; receive a first pointer to a record in thedistributed database, the record including a signed second biometrichash value; obtain, using the first pointer, the signed second biometrichash value from the distributed database; validate an identity of a userof the compute device in response to: verifying that a signature of thesigned second biometric hash value is associated with the compute deviceusing a public key of the compute device; and verifying that the firstbiometric hash value corresponds with the second biometric hash value;define a certification based on the validating; digitally sign thecertification using a private key associated with the processor toproduce a signed biometric certification; store the signed biometriccertification in the distributed database; and provide, to the computedevice, a second pointer to the signed biometric certification in thedistributed database such that the compute device can provide the secondpointer to a relying entity.
 2. The apparatus of claim 1, wherein thebiometric data includes at least one of: a fingerprint, a facial image,an iris-scan, a voice print or DNA data.
 3. The apparatus of claim 1,wherein the signed second biometric hash value is signed using a privatekey associated with the compute device.
 4. The apparatus of claim 1,wherein the processor is configured to provide the second pointer to thecompute device such that the compute device can provide the firstpointer, the second pointer, the biometric data and the public key tothe relying entity.
 5. The apparatus of claim 1, wherein the distributeddatabase is a blockchain.
 6. The apparatus of claim 3, wherein theprivate key associated with the compute device is paired with the publickey associated with the compute device.
 7. The apparatus of claim 1,wherein the encrypted biometric data is encrypted using at least one ofRivest-Shamir-Adleman (RSA) encryption algorithm or Elliptic CurveDigital Signature Algorithm (ECDSA).
 8. A method, comprising: receiving,at a processor, encrypted biometric data associated with a computedevice; decrypting the encrypted biometric data using a private keyassociated with the processor to obtain biometric data; providing thebiometric data as an input to a predefined hash function to obtain afirst biometric hash value; receiving a first pointer to a first recordin a distributed database, the first record including a second biometrichash value; obtaining, using the first pointer, the second biometrichash value from the distributed database; validating an identity of auser of the compute device in response to: verifying that a signature ofthe second biometric hash value is associated with the compute deviceusing the public key of the compute device; and verifying that the firstbiometric hash value corresponds with the second biometric hash value;and receiving, a second pointer to a second record in the distributeddatabase based on the validating.
 9. The method of claim 8, wherein thesecond record includes a signed biometric certification, the methodfurther comprising: obtaining, using the second pointer, the signedbiometric certification from the distributed database; and validating,based on the signed biometric certification, that the identity of theuser of the compute device has been certified.
 10. The method of claim8, wherein the second record includes a signed biometric certification,the method further comprising: obtaining, using the second pointer, thesigned biometric certification from the distributed database; andvalidating, that the identity of the user of the compute device has beencertified in response to: verifying that a signature of the signedbiometric certification is associated with a relying entity device usinga public key of the relying entity device; and verifying that the signedbiometric certification is associated with the second biometric hashvalue.
 11. The method of claim 8, wherein the biometric data includes atleast one of: a fingerprint, a facial image, an iris-scan, a voice printor DNA data.
 12. The method of claim 8, wherein the second biometrichash value is signed using a private key associated with the computedevice.
 13. The method of claim 8, wherein the distributed database is ablockchain.
 14. The method of claim 12, wherein the private keyassociated with the compute device is paired with the public keyassociated with the compute device.
 15. The method of claim 8, whereinthe encrypted biometric data is encrypted using Rivest-Shamir-Adleman(RSA) encryption algorithm or Elliptic Curve Digital Signature Algorithm(ECDSA).
 16. An apparatus, comprising: a memory; and a processoroperatively coupled to the memory, the processor configured to: define adata block including data to be sent to a compute device; digitally signthe data block to produce an envelope signature; generate envelopecontent including the data block and the envelope signature; encrypt theenvelope content using a public key of the compute device to produce asecure envelope; store the secure envelope at a server; and provide, tothe compute device, an identifier to the secure envelope at the serversuch that the compute device can obtain the secure envelope from theserver using the identifier.
 17. The apparatus of claim 16, wherein thedata block further includes: a seal identifier of the processor, a sealidentifier of the compute device, a timestamp, a session identifier, anda public key associated with the processor.
 18. The apparatus of claim16, wherein the data block is signed using a private key associated withthe processor to produce the envelope signature.
 19. The apparatus ofclaim 16, wherein the public key associated with the compute device ispaired with a private key associated with the compute device such thatthe compute device can use the private key associated with the computedevice to decrypt the secure envelope.
 20. The apparatus of claim 16,wherein the processor is configured to provide the identifier to thecompute device via at least one of an email, a text message, orNear-field communication (NFC).
 21. The apparatus of claim 16, whereinthe envelope content is encrypted using at least one ofRivest-Shamir-Adleman (RSA) encryption algorithm or Elliptic CurveDigital Signature Algorithm (ECDSA) to produce the secure envelope. 22.The apparatus of claim 16, wherein the identifier further includes anaddress of the server.
 23. The apparatus of claim 16, wherein theidentifier is at least one of a bar code, a QR code, or a pdf-417-code.